1. Field
The present invention concerns relocating network subnets, i.e., portions of a network to a location remote from the original network.
2. Background
Often it is desirable to run applications on a network or device in a location remote from the location where such applications are ordinarily run. For example, a programmer may wish to run an application at a location remote from a usual “home” network in which sites containing services necessary for that application are available. The programmer in this instance may face a quandary. Services necessary for the proper execution of the application at the remote location or device are available from the programmer's “home” network, but, for whatever reason, may be unavailable for the application. That is, the programmer running the application on the remote location can not take advantage of necessary services that are available from the “home” network. Such services may either be located on the “home” network, or if located elsewhere, accessible from the “home” network.
The connection failure may result from a wide variety of obstacles. In the most simple scenario, the “home” network and remote device or network may not be connected together. As another illustration, communications between the networks may not be routable due to incompatible network protocols, unfulfilled encryption requirements, or intervening devices in the network link, such as firewalls or network translation devices, etc. that tend to prevent or obstruct the routing of data between the networks. Alternatively, the network infrastructure may in some way be inadequate for delivery of such services to the remote network or the coordination of services between networks. Another scenario is that the remote location may not have enough network addresses to support all the devices necessary to run the applications. The programmer faces inherent obstacles and potentially significant network and service configuration problems.
A common infrastructure where such problems abound is the Internet. As a simple illustration, a programmer may wish to run a presentation at a remote site on the internet, such as a corporate or governmental intranet. A seamless execution of the demonstration may require that the applications that are the subject of the demonstration have access to other services on the Internet, such as a file server, DNS server, or the like, wherein the latter services are located at remote sites. Just as well, various services on the Internet may require access to these remote programs being run at the remote location on the exemplary intranet. The programmer in this situation would ideally like to have “true” Internet services at the remote location, meaning seamless access to necessary Internet sites (and vice versa) for the purposes of running the presentation.
Ordinarily, communications occur on the Internet through the routing of IP packets with a transport protocol like TCP or UDP. However, the corporate intranet may reside behind one or more devices that make such communication impractical or impossible. Such devices may include a firewall, a network address translation (NAT) box, or another device that otherwise obfuscates services or hinders communication between the Internet and the corporate intranet.
A NAT box is a mechanism that, among other functions, runs an algorithm that enables a network to use one set of IP addresses for internal traffic and another set for external traffic. In many cases, the NAT box itself has only one IP address known to components on the Internet. External sites on the Internet thus cannot identify, or associate with a routable IP address, components located behind the NAT box. Accordingly, these external sites can not initiate communicate with the internal sites or components behind the NAT box using standard IP routing. When running an application or site on the corporate intranet, necessary or desirable services residing on the Internet therefore can not route data between components on the corporate intranet or aid in the execution of the application. Likewise, depending on the network configuration, the application being run on the corporate intranet may have problems initiating communications with sites on the Internet for needed services. Communication may be desirable for many reasons, such as to transmit results of an application to a local site, to resolve or obtain network addresses, to send or receive e-mails, to use remote databases or libraries, to call remote code or libraries for local execution, etc.
Virtual private networks (“VPNs”) can often take advantage of the principles of encapsulation to provide users on a remote network with secure access to another network. Encapsulation is the process of inserting the components of a first network protocol within the packets of a second network protocol. Unfortunately, traditional VPNs only provide for the allocation of a single network address. As such, a remote subnet cannot be established. Moreover, VPNs lack continuous connectivity properties; that is, VPN connections need to be re-established whenever, for example, an address parameter changes. As an illustration of this fact, in accessing a VPN through a cable modem, the VPN may need to be torn down and re-established when the IP address at the cable modem interface changes.
Accordingly, a need exists in the art to configure and allocate a remote network such that the remote network has access to necessary services and sites without being obscured by firewalls and other devices that hinder communication, and such that communications on the remote network can remain independent of underlying networks.